The present invention relates, in general, to computers that support an object-oriented environment. More specifically, the present invention relates to an object-oriented framework that supports collection documents.
A collection document is a fiduciary instrument that is much like an xe2x80x9cI Owe Youxe2x80x9d in that one company or person promises to pay another person at a later date for goods or services. These documents are also called xe2x80x9cpromissory notesxe2x80x9d or xe2x80x9cbills of exchange.xe2x80x9d Although not used very often in the United States, collection documents are popular overseas, particularly in England, Italy, and France. The typical situation in which a collection document arises is when one company would like to receive a benefit now but pay for the benefit sometime in the future. The benefit is usually goods or services. If another company (the xe2x80x9cdraweexe2x80x9d) gives the benefit to the first company, the first company (the xe2x80x9cdrawerxe2x80x9d), in return, gives the drawee a collection document that promises payment of the debt sometime in the future. When the time for payment comes, the drawer pays the drawee the debt, which is usually money, although it could be goods or services.
One of the problems with collection documents is that they are an accounting nightmare. The transaction just described is the simplest, best possible situation for a collection document. In general, normal collection documents can proceed through a myriad of other possible situations.
For instance, if the drawee (the company that has given the benefit and received the collection document) runs into financial trouble, the drawee might sell the collection document to a bank or a third party for a reduced price. On the other hand, the drawer (the company that has received the benefit and has given the collection document) might not be able to pay or may only be able to partially pay its debt. In addition, there will be a number of other states that the collection document might be in, and these states must be tracked.
Furthermore, all of the data associated with a collection document, such as who is the drawee, how much is owed, the type of payment (e.g., money, goods, services), the date of payment, etc., must all be tracked and stored.
Lastly, many of the states and attributes associated with a collection document must be allowed to change. For instance, one company may not wish to sell their collection documents to a third party. Or, another company may not need as much information to track the collection documents as another company needs. Still other companies might wish to use only accounts receivable collection documents and not accounts payable collection documents.
What is needed is a system that allows all of the information and states associated with a collection document to be tracked, while still allowing users of a collection document to customize collection documents for their own uses.
According to the present invention, an extensible Object-Oriented (OO) framework in an object-oriented programming system defines objects and classes used to correspond to and track a collection document. The collection document can be an accounts receivable (the debt is to be received) or an accounts payable (the debt is to be paid) collection document. A collection document is an unconditional order in writing in which a debtor promises to pay a debt to a bearer in exchange for at least one benefit that has been or will be received by the debtor. The OO framework defines a collection document object that corresponds to and tracks a collection document through its many states until the collection document finally ends in an ending state. Even then, the collection document object may be retained (e.g., in a persistent or frozen state) for future reference. Each state of the collection document object corresponds to a state of the collection document.
The framework includes core classes whose inner programming cannot be changed and classes for which it is anticipated extension of the classes with new attributes and methods will occur. A program developer can customize the extensible classes to meet the needs of any application that needs to track collection documents. It is recommended that, if new attributes are desired, the extensible portion of the collection document be subclassed. In the most preferred embodiment of the present invention, the collection document object has a number of allowed states. Each state is arrived at or left through a transition. In the most preferred embodiment, the transitions themselves are extensible in that new transitions can be added, current transitions can be removed, or current transitions can be changed. By eliminating or adding transitions, states may be removed or added. Thus, not only can traditional subclassing be used to extend the functionality of the current invention, but changing transitions can also change functionality.